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DETAILED ACTION 

i> This action is in response to Applicant's after-final .remarks. Claims 1-20 are presented 
for further examination. 


2> This is a final rejection. 

Response to Arguments 

3> The previous final rejection, mailed 7.18.2005, is vacated. However, upon further 
consideration, a new ground of rejection is made in view of new prior art. 

4> Examiner respectfully disagrees with Applicant's characterization of the primary 
reference Aldred. Applicant first points to varioussections of Aldred that reference a call 
manager establishing calls [column 26 «lines 62-67»], the fact that an application must 
register itself before communicating within the system [column 35 «lines 48*67»], that it is 
up to the launched application to identify itself to the system [column 36 «lines 2i-55»]. It 
should be noted that the call manager may establish the calls but it is the first application that 
initiates such an action [column 6 «lines 20-24» where : the sending application is responsible 
for defining the channel characteristics] and that the launch_app function is issued by an 
application, not the call manager [column 29 «lines i8-i9»]. Applicant further cites to 
[column 11 «lines 34~36»] suggesting that Aldred teachings that ports are only configured 
after an application has registered with the support system. Nowhere in Aldred does he make 
this declaration; the fact that the launched application must register with the system before 
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communicating with other applications does not immediately suggest that the ports are 
configured during or after this registration period. Aldred defines that parameters can be 
passed using his launch_app function [column 36 «lines 39'40»]. Aldred also clearly states 
that the sending application is responsible for establishing and defining channel 
characteristics between applications and that channels are defined by their ports [column 6 
«lines i6-32»]. 

Examiner believes it is reasonable to suggest that the parameters passed in Aldred's 
launch_app function would be the channel characteristics needed for the launching and 
launched applications to communicate. That the launched application also returns a handle 
back to the launching application suggests that a channel has been already established 
between applications. The functionality cited by applicant, the handle being valid in veiy 
restricted circumstances until the launched application has registered, does not preclude the 
possibility that the channel and port 'information was already passed as parameters in the 
launch_app function; it merely suggests that there is limited communications until the 
applications registers its application handle with the support system so that the application 
may be recognized before they are allowed to communicate. A reason for registration might 
be to prevent already launched programs from being launched again [column 42 «lines 55- 
58»], Certainly, Aldred does not state that only after registration does the launched ( 
application receive the channel and port information as suggested by Applicant. 

Applicant also asserts that Aldred teaches away from passing port numbers as part of 
launching applications and reasserts the argument that the application first registering with a 
call manager before initiating or configuring channels and ports. This argument is not 
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persuasive. Modification of Aldred to include passing an channel and port information 
between applications does not change the principle of his invention as Aldred discloses 
passing parameters as part of the launch_app function and that the sending application is 
responsible for establishing the channel between applications. The registration functionality 
relied upon by Applicant merely suggests that the application must register before 
communications can begin. Contraiy to Applicant's assertion, Aldred does not expressly 
disclose or even suggest that the launched application registers to obtain connection 
information, but instead allows other applications know that it has already been launched 
[column 43 «lines 27'28»], In fact, the fact that a handle is returned to launching application 
and that there is return data to the launched application [column 11 «lines 36~39»] suggests 
communications between the applications after the launch_app function is initiated. The 
possibility that a channel has been already established between the applications and that the 
registration by the launched application is merely to allow other applications know that it has 
been launched imply that the launch_app function parameters are involved in providing the 
necessary information to the launched application. 

Therefore, Examiner respectfully disagrees with Applicant's assertions that Aldred 
teaches away from passing port information as part of the launch_app function and that it 
would be unreasonable to modify Aldred in that regard. Based on Aldred's definition of his 
launch_app function and the disclosure that sending applications are responsible for 
establishing channels. Examiner believes that Aldred's user defined string that is passed as 
parameters in the launch_app function suggest passing channel and port information to the 
launched application that would enable handles to be passed between the applications. 
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Further, Aldred clearly discloses a "LAKES.INI" ASCII file that contains 
customization information, stored in an appropriate repository, the applications "having 
their own additional initialization filed" and the file containing configuration and start-up 
options, devices and physical communications link and other data specific to the applications 
[column 10 «lines 37'5o»], This further supports Examiner's argument that it is inherent that 
the port numbers are stored in a memory accessible to the applications. While Aldred does 
not disclose specifically that ports are stored, it is reasonable to assume that "configuration 
options" and physical communications link are all related to the. connection (channel) 
configuration between applications. As ports are part of the configuration of the channel, it is 
inherent that the ports are stored in the LAKES.INI file that is associated with the 
applications. The fact that Aldred discloses channel & port functions that allow applications 
to modify the channel or port characteristics suggests that the applications must have access 
to the port information that allows them to modify the channel or port. Coupled with 
Aldred's showing of a customization file that is associated with the applications seems 
enough to suggest that it is inherent that the port numbers are stored in a memoiy accessible 
to the second application. 

Further, Applicant's arguments in regards to claim 5 are not persuasive. Claim 5 is 
directed towards passing a "function reference value" through a command port connection; 
lacking any clear definition in the claims, Examiner interprets "function reference value" as 
simply a reference to a function. The portion cited by Examiner in Aldred refers to how 
applications can monitor the progress of calls [functions], by allowing applications to pass 
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reference identifiers to obtain the status (progress) of a call. Applicant argues that a reference 
identifier is not a function reference value but fails in the arguments and in the claims to 
define or distinguish the term "function reference value". Based on this. Examiner believes 
interpretation of the term is "reasonable - that Aldred discloses a reference value referring to a 
function to enable applications to track progress of that function. Aldred also discloses that 
applications communicate through channels, the channels defined by the sending and 
receiving port. Thus, it is reasonable to suggest that the reference identifier is passed through 
the application's sending port. 

Finally, Applicant's arguments in regards to claim 6 are not persuasive. Claim 6 is 
directed towards passing "function parameters" through a command port connection. 
Examiner interprets the term as merely parameters associated with functions. Aldred 
discloses that his command port allow the application to drive the receipt or supply of data to 
the port [column 7 «lines 46-47»], Thus commands or functions issued by the application are 
submitted through the command port associated with the application. Aldred discloses 
submitting API commands, such as register_app, launch_app, or share functions, the 
commands clearly having function parameters, such as the application handle, application 
name, parameters for a launch_app function [see for example, column 35 «line 48» to column 
36 «line 65»], Since functions are submitted through the command port by applications, the 
parameters associated with the functions necessarily are passed though the command port as 
well. 
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Claim Rejections - 35 USC § 103 
5> The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art 
are such that the subject matter as a whole would have been obvious at the time the invention was made to a 
person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 

6> Claims 1, 12 and 20 are rejected under 35 U.S.C § 103(a) as being unpatentable over 
Aldred et al, U.S Patent No. 5.719.942 ["Aldred"], in view of Raynak et al, U.S Patent No. 
5.680.549 ["Raynak"]. 

7> Aldred discloses a method of communicating function calls or event notification 
between two applications [column 12 «lines 44'5i»], said method comprising: 

a first application launching a second application wherein the launching of the second 
application includes the first application passing parameters to the second application 
[column 5 «lines 5i-63» | column 6 «lines 39"*49» | column 7 «lines 33~62» | column 12 «lines 
57'6i»column n «lines 27'39» | column 29 «lines 8-i9» | column 36 «lines 3~52» where:. Aldred 
clearly discloses a "launch_app" function that is "issued by an application", the launch_app 
having parameters that are "given to the launched application"]. 

Aldred does not expressly disclose storing the port numbers in a memory accessible to 
the second application nor does he disclose that the parameters passed in the launch_app are 
port numbers. 
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8> Aldred do'es disclose storing a customization file in a repository, the file containing 
configuration and start-up options as well as information relating to physical links [column 

10 «lines 37-50» : LAKES.INI file] but does not explicitly disclose storing the port numbers. 
It is inherent to Aldred that the port numbers are stored in a memory accessible to both 
applications because Aldred discloses the LAKES.INI file contains configuration, start-up, 
and physical link information. Ports are related to configuration and physical link 
information of the applications. Furthermore, applications are able to alter ports and channels 
after having been initially established [column 8 «lines 49-.55» | column 12 «lines 36-42»]. 
Therefore, the port and channel information must be stored in a place, such as the 
LAKES.INI file associated with the applications, that can be accessed by the applications in a 
manner that enables them to modify them as disclosecl by Aldred. One would have been 
motivated to perform such an implementation as storing connection (port) information for 
applications is expected and well known in the art as it allows the applications to maintain 
connection flexibility. 

9> While Aldred does not expressly disclose passing ports as parameters in the 
launch_app function. However, such functionality is suggested by Aldred's disclosure that a 
sending application is responsible for establishing channels and the channels being defined 
by ports [column 6 «lines 17~32»]. Further, Aldred discloses that after an application has been 
launched, the launched application's handle is returned to the launching application [column 

11 «lines 33"34 >> ] a ^d there is return data to the launched application [column 11 «lines 36-38»]. 
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Such functionality suggests that a channel has already been established between the launched 
and launching application. 

Further, Raynak is directed towards a system for enabling a first application to invoke 
a second application. The first application passes to the second application port and 
connection information as part of launching the second application as command-line 
parameters [Figure 4 | column 1 «lines n-24» | column 6 «lines 32-57»]. Examiner notes that 
the second application uses the port information to take over the connection from the first 
application, and thus is not completely analogous to the second application in Aldred. 
However, the functionality relied upon in Raynak is that port and other connection 
information is transmitted by a launching application to a launched application. It would be 
obvious to one of ordinary skill in the art to incorporate Raynak' s command-line parameters 
into Aldred's launch_app parameters to enable the launched application. As mentioned, 
Aldred's disclosure of handle and return data being transmitted between the launched 
application and the launching application in response to the launch_app function suggests 
that a connection is established between the applications. Thus, Raynak's command-line 
parameters teaches that Aldred's launch_app parameters could include port information. 

io> As claim 12 is merely an article that performs the steps of the method of claim 1, it 
does not teach of further define over the limitations of claim 1. Therefore, claim 12 is rejected 
for the same reasons set forth in claim 1, supra . 


n> 


As to claim 20, Aldred discloses a device, comprising: 
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a processor [column 3 «lines 65-66»]; 

a memory coupled to the processor [column 3 «lines 6y6y» | column 4 «lines 39'43»], 
wherein the memory comprises program 
instructions configured to implement: 

the limitations of the method of claim 1 [see claim 1, supra], 

I2> Claims 2-6, 8-11, 13*17, and 19 are rejected under 35 U.S.C § 103(a) as being unpatentable 
over Aldred and Raynak, in further view of Simonoff et al, U.S Patent No. 6.005.568 
["Simonoff"]. 

I3> As to claim 2, Aldred does not explicitly disclose the method comprising the second 
application connecting a TCP/IP client socket to the event port. 

I4> Connecting a TCP/IP socket to a port is well known and expected in the art. For 
example, Simonoff discloses establishing a socket connection on a given port [column 8 
«lines 63-65» | column 10 «lines i3-27»]. In addition, it is well known in the art that sockets 
are commonly defined in part by a port address. Therefore, as Aldred discloses event ports as 
endpoints to the two-way communication channel, it would have been obvious to one of 
ordinary skill in the art to have reasonably inferred that TCP/IP socket functionality would 
have been included in Aldred's system. 
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I5> As to claim 3, Aldred does not explicitly disclose the method comprising connecting a 
TCP/IP client socket to the command port, 

i6> Connecting a TCP/IP socket to a port is well known and expected in the art. For 
example, Simonoff discloses establishing a socket connection on a given port [column 8 
«lines 63-65» | column 10 «lines i3-27»]. In addition, it is well known in the art that sockets 
are endpoints of a two-way communication link and are commonly defined in part by a port 
address. Therefore, as Aldred discloses command ports as endpoints to the two-way 
communication channel, it would have been obvious to one of ordinary skill in the art to 
have reasonably inferred that TCP/IP socket functionality would have been included in 
Aldred's system, and specifically, that establishment of the TCP/IP socket would connect to 
both ports located on either end of the channel. 

I7> As to claim 4, Aldred does disclose storing the connection parameters of streams 
between applications [column 4 «lines 44-54» | column 7 «lines 44~62» | column 8 «line 56» to 
column 9 «line 5»]. 

It is well known in the art that sockets are endpoints of a two-way communication 
link and are commonly defined in part by a port address. Therefore, as Aldred discloses event 
ports as endpoints to the two-way communication channel, it would have been obvious to 
one of ordinary skill in the art to have reasonably inferred that TCP/IP socket functionality 
would have been included Aldred's system, and specifically, that the Aldred's stream 
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connection parameters (IP address, bandwidth, ports, quality of service, etc.) would be 
applied to client sockets. 

i8> As to claim 5, Aldred discloses the method of claim 2, further comprising passing a 
function reference value through the command port connection [column 24 «lines 52-6i»]. 

I9> As to claim 6, Aldred discloses the method of claim 3, further comprising passing a 
function parameter through the command port connection [column 24 «lines 39'42» | column 
35 «line 48» to column 36 «line 65» : see for example, the "parameters" passed along with the 
launch_app function]. 

20> As to claim 8, Aldred discloses the method of claim 2, further comprising passing an 
event notification tag through event port connection [column 31 «line 59» to column 32 «line 
6 7 »]. 

2i> As to claim 9, Aldred discloses the method of claim 8, further comprising checking 
the event port for an event notification tag [column 25 «lines 2y2j» | column 30 «lines 48-5i» 
where: the command initiates monitoring for events at the port]. 

22> As to claim 10, Aldred discloses the method of claim 9, further comprising checking 
the command port in response to receiving an event notification tag [column 25 «line 53» to 
column 26 «line io»]. 
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23> As to claim 11, Aldred discloses the method of claim 9, passing through the event port 
connection an event port notification tag relating to the completion of a function [column 37 
«lines i-9»]. 

24> As to claims 13-17 and 19, as they are merely articles that perform the steps of the 
method of claims 2-6 and 8, respectively, they do not teach or further define over the 
limitations of claims2-6 and 8. Therefore, claims 13-17 and 19 are rejected for the same reasons 
set forth for claims 2-6 and 8, supra . 

25> Claims 7 and 18 are rejected under 35 U.S.C § 103 (a) as being unpatentable over 
Aldred, Raynak and Simonoff, in further view of Jalili et al, U.S Patent No. 5.423.042 
["jalili"]. 

z6> Simonoff does disclose the method of claim 5 further comprising passing a value of 
memory location [column 36 «lines 34'37»] but does not specifically disclose storing a result 
of a function trigger by the passing of the function reference value. 

27> Jalili discloses passing a value of a memory location for storing result of a function 
trigger by the passing of the function reference value [abstract | column 10 «lines 33'48»]. It 
would have been obvious to one of ordinary skill in the art to incorporate Jalili's memory 
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location for storing results of functions into Simonoffs pointer functionality to 
communicate to the second application where to store the results of a function. 

28> As claim 18 is merely an article that performs the steps of the method of claim 7, it 
does not teach of further define over the limitations of claim 7. Therefore, claim 1281s rejected 
for the same reasons set forth in claim 7, supra . 

Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisoiy action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the 
advisory action. In no event, however, will the statutory period for reply expire later than 
SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Dohm Chankong whose telephone number is (571)272-3942. 
The examiner can normally be reached on 8:30AM - 5:30PM. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Glenton Burgess can be reached on (571)272-3949. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published 
applications may be obtained from either Private PAIR or Public PAIR. Status information 
for unpublished applications is available through Private PAIR only. For more information 
about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on 
access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217- 
9197 (toll-free). 


DC 
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Primary Examine- 


